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@ Method and apparatus for transmission of high priority traffic on low speed communication links. 



@ In a packet switched communications system an 
incoming real-time packet is imbedded after the next 
block of data of the non-real-time packet being trans- 
mitted. 

This object is accomplished by transmitting each 



packet along with at least a 1-byte trailer which is 
used to indicate the packet type, whether the current 
block of non real time data is preempted or whether 
the current block of non real time data is resumed. 
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Field of the Invention 

This invention relates to telecommunications 
networks and more particularly to an improved 
preempt/resume protocol for low-speed commu- 
nication links in a fast packet switch ing network. 

Background of the Invention 

In a digital transmission network, data from a 
large num ber of users are serially transmitted from 
one network node to another network node, up to 
their respective final destination. 

Due to the evolution of networks towards more 
and more complex mixings of sub-networks with 
heterogenous archi tectures, it is clear that there is 
a future requirement to support distributed comput- 
ing applications across high speed backbones that 
may be carrying LAN traffic, voice, video and traffic 
among channel-attached hosts and work stations. 
Perhaps the fundamental challenge for high speed 
networking is to minimize the processing time with- 
in each node in the network. 

Packet switching is now commonly used to 
accomodate the bursty, multiprocess communica- 
tion found in distributed computing environments. 
To accomplish this, packets carry ing bursty data 
traffic can be assigned a non-real-time priority, 
while packets carrying voice and video traffic can 
be assigned a higher, real-time priority. A node in a 
fast packet switching network contains buffers for 
holding packets waiting for transmission on its 
communication links. Packets waiting for transmis- 
sion can be held in buffers managed differently, 
depending on the priority, assigned to the packets. 

European patent application (582537) discloses 
a communication network having communication 
nodes which can adopt a number of different ser- 
vice policies in order to transmit packets from 
different priority buffers, for instance, priority with 
no preemption, preemption with retransmission, 
and priority with resume. When no preemption is 
used, the packet priority is only examined to deter- 
mine from which buffer to select the next packet 
for transmission. If a high-priority packet is placed 
in the buffer while a iow-priohty packet is being 
transmitted, the high-priority packet must wait until 
the current transmission is completed. A preemp- 
tion with retransmission service policy means that 
the node will abort the transmission of a low- 
priority packet upon the arrival of a high priority 
packet and transmit the high-priority packet. Once 
alt high-priority packets have been transmitted, 
transmission of the preempted low-priority packet 
will be restarted from the beginning of the packet. 
A preemption with resume service policy is similar, 
except the preempted low-priority packet is re- 
started from the point of interruption rather than the 



beginning. The se lection of the appropriate service 
policy is dependant on the characteristics of the 
communication link, the delay requirements of the 
high-priority packets, and the size of the low-prior- 

5 ity packets. 

The typical scheme used for transmitting pac- 
ketized infor mation over low speed communication 
links (T1 at 1.544 megabits per second) is based 
on the HDLC MAC-layer protocol, described, for 

10 exemple, in H. NUSSBAUMER: TELEINFORMAT- 
IQUE I, Presses Polytechniques Romandes, 1987, 
pages 301-313. 

Both the priority with no preemption and the 
preemption with retransmission service policies can 

/5 be implemented using the existing HDLC MAC- 
layer protocol- For preemption with resume service 
policy, a modified HDLC MAC-layer protocol is 
described wherein three types of flags are used to 
delimit packets for allowing high-priority packets to 

20 temporarily preempt low-phority packets. The 
HDLC starting, ending or idle flag is defined as the 
8-bit sequence B'011 1 1 1 10*(X*7E*). The start pre- 
empt flag is defined as the 9-bit sequence 
B'011111110' and the end-preempt flag is defined 

25 as the 1 0-bit sequence B'01 1 1 11 1 11 0'. All flags are 
on byte boundaries with respect to the packet data 
that they delineate. 

This definition requires that the hardware is 
capable to scan the incoming bit stream, to recog- 

30 nize special non-standard flags in addition to the 
HDLC flags, and to run a protocol to verify a set of 
rules upon detection of these flags. Clearly, a spe- 
cial hardware is necessary for that purpose. 

35 Objects of the invention 

It is therefore a principal object of the invention 
to provide a method and an apparatus for embed- 
ding high-priority traffic in low-priority traffic for 
40 serial transmission through low speed communica- 
tion links, without delay incurred by having first to 
complete transmission of a low-priority traffic. 

It is another object of the invention to preempt 
low-priority packet traffic with at least one high 
45 priority packet and later resume transmission of the 
preempted low-priority packet automatically, using 
an output adapter built with off-the-shelf scanners. 

It is another object of the invention to allow a 
mode of operation that is compatible with the 
50 HDLC MAC-layer protocol. 

Brief Summary of the Invention 

According to the invention an incoming real- 
55 time packet is imbedded after the next block of 
data of the non-real-time packet being transmitted. 

This object Is accomplished by transmitting 
each packet along with at least a 1-byte trailer 
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which is used to indicate the packet type, whether 
the current block of non real time data is pre- 
ennpted or whether the current block of non real 
time data is resumed. 

Brief Description of the Drawings 

The invention will be described with respect to 
a preferred embodiment thereof, which is further 
shown in the drawings in which: 

Figure 1 is a block diagram representing the 
output adapter of a node of a network within which 
the invention may be practiced. 

Figure 2 represents the principle of the pre- 
empt/resume mechanism according to the inven- 
tion. 

Figure 3 represents the configuration of a trail- 
er byte according to the invention. 

Figure 4 shows a point to point T1 line connec- 
tion. 

Figure 5 is a model of the different transmit 
sequences. 

Figure 6 to 10 are different transmit sequences. 
Figure 11 is a Preempt/Resume Transmit flow 
diagram. 

Figure 12 is a Preempt/Resume Receive flow 
diagram. 

Figure 13 is a block diagram of the transmit 
portion of a trunk interface of a communication 
system to which the invention is applicable. 

Figure 14 is a block diagram of the receive 
portion of a trunk interface of a communication 
system to which the invention is applicable. 

Detailed Description of Preferred Embodiment of 
the In vention 

A packet-switching network usually consists of 
switching nodes and communication links or trunks 
between these nodes. Each of those nodes is 
linked to at least one other node* through one or 
more communication links. The switching nodes 
are data processing systems including trans- 
mit/receive adapters connected to the communica- 
tion links. At each node, incoming data packets are 
selectively routed to one or more of the outgoing 
communication links terminated at another node. 
Such routing decisions are made in response to 
information in the header of the data packet. 

In a packet switching network, packets are 
pieces of data, which are prefixed with headers 
containing control and routing information that iden- 
tifies the originating and destination users. Each 
node examines each header and decides where to 
send the packet to move it closer to its destination. 

A basic requirement of high speed networks is 
to selectively process data according to different 
classes of services, which are generally specified 



in terms of probability of loss and maximum end- 
to-end delay. This class of service may be speci- 
fied by some bits in the header, which are decoded 
at intermediate nodes to select the buffering policy. 

6 Delay priorities are specified among three 

classes of traffic. At each output trunk adapter, 
packets from each class share a different logic 
buffer before being transmitted over the trunk. 
These classes are; 

10 - Real-time traffic (voice, video), 

- Non-real-time traffic (data), 

- Non-reserved traffic (datagram). 

Figure 1 represents the output adapter struc- 
ture, featuring three buffers 10, 11, 12, a scheduler 

75 20, and a scanner 30. Packets received from the 
switch are stored in one of the buffers, according to 
their class, and the scheduler implements a policy 
to forward these packets to the output trunk. The 
scanner implements the low-level of the DLC pro- 

20 tocol (frame synchronization. 0 insert/delete, CRC). 
The scheduler implements the preempt/resume 
protocol which will be described later. 

Re al-time traffic is given priority over non-real- 
ti me traffic in . order^tOL-T^^luce-lts delay. Both~^real- 

25 time and non-real-time traffics are given priority 
over non-reserved traffic in order to minimize the 
impact of this class on the band-width reservation 
mechanism. For the sake of convenience, both 
non-real-time traffic and non reserved traffic will be 

30 considered as low priority traffic. Within each class, 
the packets are served in sequence, that is in the 
same order they arrived. Depending on the trunk 
speed, the scheduling policy is either preemptive 
or nonpreemptive. 

35 In the case of non-preemptive policy, the buffer 

with the lower priority class is served only if the 
buffer with the highest priority class is empty, and 
the service of the low. priority packets is not inter- 
rupted even when a high priority packet arrives 

40 before the end of the service. ' 

This policy is used on all links for which the 
service time of a maximum-length non-real-time 
packet is less than 1.5 ms. For example, a T3 link 
supporting 2 Kbyte maximum length packets would 

45 use a nonpreemptive policy (0.3 ms maximum ser- 
vice time). 

In the case of a preemptive resume policy, the 
buffer with the lower priority class is served only If 
the buffer with the highest priority class is empty, 

50 and the service of the low priority packets is inter- 
rupted when a high priority packet arrives before 
the end of the service. The service of the low- 
priority packet is resumed after the high-priority 
packet has been served. 

55 This policy is used on all links for which the 

service time of a maximum-length non-real-time 
packet exceeds 1.5 ms. For example, a Tl link 
supporting 2 Kbyte maximum length packets would 
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use a preemptive with resume policy (10 ms ser- 
vice time). 

This low speed interface uses the standard 
HDLC protocol: the X7E' flag indicates the start- 
.ing/ending of a packet. This flag is a shared start- 
ing and ending flag, i.e. one flag between packets, 
that defines byte alignment and is sent during idle 
periods. Having the X'7E' define byte alignment 
means that all packets using the network basic 
packet format are an integer number of bytes in 
length. 

The HDLC receiver looks for X'7E' to synchro- 
nize the starting/ending of a packet. To assure that 
this bit pattern does not appear in the packet, zero 
bit stuffing is used. The HDLC transmitter Inserts 
an extra 0 bit after each occurrence of five I's in 
the data to be transmitted. The HDLC receiver 
monitors the bit stream for a pattern of five Vs. If 
the sixth bit is a zero, then it is deleted. If the sixth 
bit is a one. the seventh bit is a zero, and it is byte 
aligned, then this is a X'7E' flag. If the X'7E' flag is 
not byte aligned, then it is an abort flag, a non- 
aligned X'7E'. 

A node must always be able to send and 
receive link-initialization and link liveness mes- 
sages. These messages are only sent using the 
basic packet format for low-speed bit level inter- 
faces. 

T he decision o f,^ ^wbe.tber_to ._ use pre- 
em pt/resume protocol and HDLC frame format^ are 
determined dunnglink;^ If both nodes 

agree to support connection oriented LLC, the 
HDLC frame format is used. In the HDLC frame 
format, data is sent using Information frames and 
link state transition exchange is sent using Unnum- 
bered Information frames. 

In the system described in the prior art, the 
preempt/ resume protocol uses a couple of special 
flags: 

'011111110*: Starting preempt flag 
'0111111110*: Ending preempt flag 
Both flags are byte aligned. 

Let's assume that a non-real-time packet is 
ready to be transmitted at time t 1, and that no 
real-time packet is ready to be transmitted. Then, 
the transmission of the non-real-time packet can 
begin at time ti. Now assume that a real-time 
packet arrives at the output trunk at time t 2 before 
the end of the transmission of the non-real-time 
packet. The packets are sent from the queue to the 
trunk adapter on a byte basis, and a real-time 
packet can be inserted after any byte of a non-real- 
time packet, provided it is encapsulated between a 
starting preempt flag (SP) and an ending preempt 
flag (EP). During the reception of the packet, the 
receiver looks for the starting preempt flag. Upon 
detection of this flag, It checks the validity of the 
detection, and eventually starts receiving the real- 



time packet that has been imbedded within the 
non-re al-time . packet. It also continues looking at 
the received bits, detects the ending preempt flag, 
then checks the validity and resumes the reception . 
5 of the non-real-time packet. 

The validity of the preemption is defined by the 
following set of rules: 

- X'7E' defines byte alignment. 

- Six I's preceded by a 0 that is not byte- 
10 aligned is an invalid code. 

- Nine Vs preceded by a 0 that is not byte- 
aligned is an invalid code. 

- Receipt of an invalid code aborts the current 
packet and subsequent packets, until X'7E'. 

75 - Must verify that the preempted packet is a 

non-real-time packet (C1 bit of control byte 1 
in the network header must be 1). 

- Must verify that the packets received during 
preemption are real-time packets (CI bit of 

20 control byte 1 in the network header must be 

0). 

- Cannot preempt a non-real-time packet be- 
fore first byte is transmitted, because first 
byte is used to determine if the packet is 

25 real-time or non-real-time. 

The invention will now be described with refer- 
ence to Figure 2. \X is easy to observe that in any 
case, the real-time traffic can support a small delay 
before being scheduled, provided this delay is 

30 bounded by a small maximum delay T. For exam- 
ple, one can consider that for a voice connection a 
maximum 1.5 ms delay per node is af fordable, 
when compared to the 100 ms maximum end-to- 
end delay that is usually agreed on. Under this 

35 assumption, the preemption granularity can be de- 
fined at a block level instead of a byte level. In 
other words, instead of imbedding an incoming 
real-time (RT) packet after the next byte of the 
non-real-time (NRT) packet being transmitted, one 

40 can schedule its transmission for the next block of 
data of the packet being transmitted. 

On trunks that support preempt/resume pro- 
tocol, each packet is transmitted along with at least 
a 1-byte trailer which is used to indicate whether 

45 the packet is preempted. Each preempt/resume 
transition is marked by the transmission of a X'7E' 
flag preceded by a 1-byte trailer. 

NRT (and NR) packets are segmented into 
short blocks (NO = 128 bytes). The scheduler 

50 sends each block over the line after it has checked 
that the RT queue is empty. At TI speed, the block 
length corresponds to a 0.7 microsecond transmis- 
sion delay. 

If a RT packet arrives after the transmission of 
66 a NR or NRT packet has started, the scheduler 
notices the presence of that packet at the next 
inter-block checking. It then inserts a 1-byte trailer 
which indicates that this packet is going to be 
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preempted by at least one RT packet, triggers the 
transmission of a X'7E' flag and inserts the RT 
packet. 

After the RT packet has been transmitted, the 
scheduler inserts a 1-byte trailer which indicates 
that this packet was a RT packet, triggers the 
transmission of a X'7E' flag, and checks again the 
RT queue, if the RT queue is empty, the scheduler 
resumes the transmission of the NRT (or NR) pack- 
et. Else, it transmits the next RT packet and then 
inserts a new 1-byte trailer and a XVE' flag. 

Figure 2 shows the principle of the pre- 
empt/'resume protocol. Let's assume that the trans- 
mission of a non-real-time packet has started at 
time t = t 1, and that a N 1 byte real-time packet 
arrives at time t = t 2. The real-time queue is 
checked before sending a new block of the non- 
real time packet, so in our example the preemption 
will be activated at time t 3 - t 1 + T. After the 
real-time packet has been transmitted, the trans- 
mission of the non-real-time packet is resumed by 
blocks of N 0 bytes. 

The trailer byte actually includes 

- Only three state control bits that are used by 
the preempt/ resume protocol. 

- One reserved bit and 

- Four other bits used for protection. 
Figure 3 shows a trailer byte wherein: 

BO to B3: Trailer byte checksum. Equal to 
the inverted value of bits 84 to 87. 
84: Reserved 
85: PT (Packet Type) bit: 

0 Real-Time 

1 Non-real time / Non reserved 
86: PB (Preempted Block) bit: 

NRT (85 = 1) 

0 Current block is not preempted 

1 Current block is preempted 

RT (85 = 0) 

0 Not applicable 

1 Always inserted RT packet 
B7: RB (Resumed Preempt) bit: 

NRT (85 = 1) 

0 Current block is not resumed 

1 Current block is resumed 

RT (85 = 0) 

0 Not last RT packet; next = RT 

1 Last RT packet; next = NRT 
Instead of using 4 parity bits, one could use an 
error correcting code which would correct all single 
errors in a trailer byte. 

The different Preempt/Resume sending se- 
quences will now be described with reference to 
Figures 4-10. 

The data sequences described hereafter are 
those generated at the transmit side (sender trunk) 
then received at the other side (receiver trunk) thru 
a point to point T1 line connection, as shown in 



Figure 4. 

In the following text and figures 

- NRT stands for non-real-time and .non-re- 
served types of data packets. 

5 - TB stands for Trailer Byte. 

- F stands for X'7E' delimiter flag. 

Data sequence models are represented ac- 
cording to the model of Figure 5 
All possible sending sequence types generated by 
10 the sender are: 

- Single NRT packet not preempted. 

- Single RT packet not inserted. 

- Preempted NRT packet, single preemption 
with one RT packet insertion. 

15 - Preempted NRT packet, single preemption 
with several RT packets insertion. 

- Preempted NRT packet, multiple preemption. 
The sequence of Figure 6 represents a Single 

NRT packet, where T100 TB means: NRT com- 
20 plete packet, i.e. not pre empted, not resunjed. 

The sequence of Figure 7 represents a Single 
RT packet where TOOO TB means: RT PACKET, 
not inserted. 

The sequence of Figure 8 represents a NRT 
25 packet preempted ONCE with one inserted RT 
packet, where T110 TB means: NRT, preempted. 
FIRST BLOCK of packet, T011 T8 means: RT 
PACKET, inserted, followed by a NRT BLOCK. 
T101 TB means: NRT. resumed, LAST BLOCK of 
30 packet. 

The sequence of Figure 9 represents a NRT 
packet preempted ONCE with several inserted RT 
packets, where T110 TB means NRT. preempted, 
FIRST BLOCK of packet, T010 TB means RT 
35 PACKET, inserted, followed by another RT PACK- 
ET, T011 TB means RT PACKET, inserted, fol- 
lowed by a NRT BLOCK, T101 TB means NRT. 
resumed, LAST BLOCK of packet. 

The sequence of Figure 10 represents a NRT 
40 preempted SEVERAL times (SEVERAL inserted RT 
packets), where T110 TB means: NRT, preempted, 
FIRST BLOCK of packet, T01 1 TB means: RT 
PACKET, inserted, followed by a NRT BLOCK, 
T111 TB means: NRT, preempted, resumed, MID- 
45 OLE BLOCK of packet. T010 TB means: RT PACK- 
ET, inserted, followed by another RT PACKET, 
T011 TB means: RT inserted, followed by a NRT 
block, T101 TB means: NRT, resumed, LAST 
BLOCK of packet. 
50 Figures 11 and 12 show the Preempt/Resume 

Transmit and Preempt/Resume Receive flow dia- 
grams, respectively. 

In these flow diagrams, a block always referen- 
. ces a part of a NRT packet. A NRT block size is 
55 determined at the transmission side at the time the 
currently transmitted NRT packet is preempted. 

A preempted NRT packet is reconstructed at 
the receive side by concatenating NRT blocks of 
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the same packet, received consecutively, starting 
with the first block, continuing with the middle 
block(s) if any. and terminating with the last block. 
First, middle and last block indications are derived 
fronn the state control bits of the Trailer Byte of 5 
each block. 

A Packet references 



1. A single RT packet. This type of packet is 
never segmented 

2. A single NRT packet i.e. a non preempted 
packet. 

In the case of a receiving sequence error, all 
blocks of the same NRT packet, accumulated since 
the first one has been received, AND the latest 
received block/packet are discarded. 

A valid Trailer byte means the received 
block/packet is apparently correct: 

- good X'7E* flag alignment, - checksunn field 
of the Trailer byte validates the whole byte. 

In this case the information provided by the 
Trailer byte is considered as good. Thanks to this 
information the type of the next block/packet to be 
received may be predicted. 

An invalid Trailer byte causes the received 
block/packet being discarded. The type of the next 
block/packet to be received cannot be predicted. 

The different states characterizing the system 
at the receive side are shown on Figure 12: 

IDLE state. 

This is the default state, entered at initialization 
time and when receiving no data from the line. 
IDLE state is left when receiving a first valid pre- 
empted NRT data block. 

PR-RT state. 

This state means the preempt-resume process 
has been started or is in progress. PR-RT state is 
entered at the end of the reception of a valid first 
NRT block at IDLE state or at the end of the 

reception of a valid middle NRT block at PR NRT 

state. A RT packet is expected. The Trail er byte of 
any valid received RT packet indicates the follow- 
ing expected data is either another RT packet or a 
resumed NRT block. In the case of a resumed 
NRT block, PR_NRT state is entered. 

PR__NRT state. 

This state means the preempt-resume process 

is in progress. PR NRT state is entered at the end 

of the reception of a valid last RT packet at PR-RT 
state. NRT block is then expected. Two cases can 
occur: - A middle NRT block is received, Le. next 



expected data is a RT packet then the PR-RT state 
is entered. - A last NRT block is received, i.e. 
terminating the NRT packet accumulation then 
IDLE state is entered. 

RT state. 

This state means the preempt-resume should 
be in progress. PR-RT state has been entered from 
10 any other state where an unexpected block/packet 
has been received with a valid trailer byte. This 
state allows the recovery of valid RT packets from 
a corrupted preempt/resume sequence (ex altered 
X'7E' end flag of a block/packet). RT state is left 
75 and IDLE state is entered as soon as a last RT 
packet or any non valid block/packet is received. 

Figure 13 shows a block diagram of the trans- 
mitter 40 portion of the trunk interface of that 
communications system. Packets arrive from the 
20 communications system's packet source 41 for 
transmission on communication link 48. The pack- 
ets may have been generated locally by this sys- 
tem or may have been received from another trunk 
on this system (e.g. an Intermediate node in a 
26 packet net work). The communications system 
places the high-priority packets into a high priority 
buffer 42 and places the low- priority packets into a 
low priority buffer 43, If no packets are stored In 
either high priority buffer 42 or low priority buffer 
30 43. a flag generator 46 is connected to the commu- 
nication link 48 via a bit multiplexer 47. The flag 
generator 46 repeatedly generates an idle flag 
X'7E'. when no packets are stored for transmission. 
When a low-priority packet arrives in the low 
35 priority buffer 43 and a packet is currently being 
transmitted, the transmitter 40 waits until all earlier 
packets In the low priority buffer 43 have been 
transmitted and the high priority buffer 42 Is empty. 
When a low-priority packet is at the head of the low 
40 priority buffer 43 and no other packet is being 
transmitted on the communication link 48, bytes 
from the low priority buffer 43 are transferred one 
at a time through a byte multiplexer 44 to a parallel 
serial converter 45. The parallel serial converter 45 
45 serializes the data and monitors the outgoing data 
for sequences of five consecutive 'V bits. It also 
inserts a single '0' bit immediately after each set of 
five '1* bits. The resulting bit stream is routed 
through the bit mux to the communication link 48. 
50 When the transmission of the low-priority packet is 
complete, the bit multiplexer 47 selects the flag 
generator 46 for transmission to send at least one 
or more normal flags until the next packet is ready 
to be transmitted. Note that each time a flag is 
55 sent, the parallel serial converter 45 resets its inter- 
nal count of the number of consecutive 'V bits. 

If a low-priority packet is being transmitted 
from low priority buffer 43 and a high-priority pack- 
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et arrives in the high priority buffer 42, then the 
transnnission of the low-priority packet is preempt- 
ed. The remaining bits in the parallel serial con- 
verter 45 along with any stuffed zero bits are 
transnnitted guaranteeing a block boundary for the 
preempted packet. Then the flag generator 46 
sends a trailer byte, as described earlier and an 
idle flag X'7E'. Bytes from the high priority buffer 
42 are then transferred through the byte multi- 
plexer 44 to the parallel serial converter 45 which 
performs serialization and zero bit stuffing. The 
resulting high-priority packet is then transferred to 
the communication link 48. If. during the transmis- 
sion of the high-priority packet, another high-prior- 
ity packet arrives in the high-priority buffer 42, then 
the flag generator 46 sends a trailer byte and an 
idle flag when the first high-priority packet is com- 
pleted and transmitter 40 begins transmission of 
the next high- priority packets without exiting the 
preempt mode. When the last of the series of high- 
priority packets has been sent (there are not more 
packets waiting in the high priority buffer 42), the 
flag generator 46 sends again a trailer byte and an 
idle flag. The remaining bytes from the preempted 
low-priority packet in the low priority buffer 43 are 
released to the parallel serial converter 45 and the 
communication link 48. If a subsequent high-prior 
ity packet arrives at the high-priority buffer 42 prior 
to the completion of the preempted low-priority 
packet, the preemption and resume sequence is 
repeated. When the transmission of the low-priority 
packet is completed, the flag generator 46 trans- 
mits an idle flag. 

Figure 14 shows a block diagram of the re- 
ceiver 50 portion of the communication link inter- 
face of the communications system up to a point at 
which received whole packets are passed to a 
packet target 56 within the communications sys- 
tem. The packet target 56 could be the final des- 
tination for the received packets or could be a 
packet switch used to route packets to other trunks 
for transmission to other nodes in a packet net- 
work. Any buffering associated with the packet 
target 56 is outside the receiver 50 and is not 
included in Figure 14. 

A flag detector 52 continuously monitors the bit 
stream received from a communication link 51 trail- 
er byte and idle flags. If a sequence of bits other 
than a flag is detected immediately following an 
idle flag, it indicates the beginning of a new frame. 
A serial parallel converter 53 receives the bit 
stream, discard any '0' bit if it immediately follows 
five consecutive M* bits, and con verts the remain- 
ing bits into byte-parallel form. If the received 
packet is a high-priority , packet, the parallel byte 
data is passed directly through a multiplexer 59 to 
a multiplexer 55 connected to the packet target 56 
until a normal ending flag is detected by the flag 



detector 52. The receiver 50 indicates the end of 
the packet to the packet target 56. 

If the received packet can be preempted (i.e. 
low-priority, non-real-time packet), then the parallel 

5 byte data is instead passed through byte mul- 
tiplexer 59 to the preemptable packet buffer 54 in 
order to permit the entire packet to be accumulated 
before passing it to the packet target 56. If flag 
detector 52 detects a trailer byte that there is no 

70 partial byte in the serial parallel converter 53. then 
it indicates the beginning of a high-priority pre- 
empting packet and therefore the beginning of pre- 
empt mode. The bit stream is passed through the 
serial parallel converter 53 as before but this time 

75 the parallel byte data is passed directly through the 
multiplexers 59 and 55 to the packet target 56 
within the communications system. 

When the flag detector 52 detects either a 
normal ending flag or a trailer byte indicating the 

20 end of preemption, then the receiver 50 indicates 
the end of the packet to the packet target 56. If a 
normal ending flag is detected, then the serial 
parallel converter 53 will continue to route the 
parallel byte data from subsequent packets directly 

25 to the multiplexer 55. If a trailer byte indicating the 
end of preemption is detected, the receiver 50 will 
end preempt mode. The received bit stream will be 
routed through the serial parallel converter 53 and 
multiplexer 59 to the preemptable packet buffer 54 

30 thus resuming reception of the preempted low- 
priority packet . If the flag detector 52 detects a 
normal ending flag indicating the end of the low- 
priority packet, the receiver 50 transfers the entire 
low-priority packet stored in the preemptable pack- 

35 et buffer 54 through the multiplexer 55 to the 
packet target 56, 

Claims 

40 1. A packet-switched communications system for 
transmitting low-priority packets segmented in 
short blocks and high priority packets char- 
acterized in that it comprises : 

- means for embedding high-priority pack- 
45 ets within low-priority packets based on 

distinctive bit patterns attached to each 
block of said low-priority packets and to 
each of said high-priority packets; 

50 2. A system according to claim 1 wherein said 
means for embedding high-priority packets 
within low-priority packets comprises : 

- means responsive to a first distinctive bit 
pattern for transmitting the high-priority 

55 packet before the next block of low-prior- 

ity packet, 

- means for buffering the next blocks of 
the low-priority packet that is preempted 
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by the high-priority packet, and 
- means responsive to a second distinctive 
bit pattern for resuming transmission of 
the blocks of the low-priority packet tem- 
porarily stored in said buffering means. 5 

3. A system according to claim 2 further compris- 
ing means for checking whether or not a high- 
priority packet is to be transmitted. 

10 

4. A system according to claim 3 further compris- 
ing means for prefixing each packet with a 
starting flag. 

5. A system according to anyone of claims 1-4 75 
wherein said distinctive bit pattern is a trailer 
byte. 

6. A method for embedding high-priority packets 
within a low- priority packet segmented in 20 
short blocks in a packet-switched communica- 
tions system, characterized in that it comprises 

the steps of : 

a. prefixing each low-priority packet with a 
starting flag ; 25 
b- suffixing each low-priority packet with a 
distinctive bit pattern ; 

c. suffixing each high-priority packet with a 
distinctive pattern of bits ; 

d. using the starting flag to initiate transmis- 30 
sion of packets and to establish byte align- 
ment with a packet frame ; 

e. using a first distinctive pattern of bits to 
interrupt the . transmission of low-priority 
packets and buffer untransmitted low-prior- 35 
ity while transmitting a high-priority packet ; 

f. using a second distinctive pattern of bits 
following the completion of transmission of 
a high-priority packet to indicate the re- 
sumption of the transmission of the inter- 40 
rupted low-priority packet ; and 

g. using the ending flag to return the com- 
munications system to an idle state. 



55 



8 



I 



EP 0 684 719 A1 



Real— time 



10 



From 



Switch 



Non— real— time 11 



Non — reserved 



TRAFTIC 
SCHEDULER 



SCANNER 



To 



Trunk 



20 



30 



12 



FJLG . 1 



Ncn real time user date ovaiiable ot time t1 



BLX1 



BLK2 



BLK3 



Real time user data avcilcble at time t2 



Oato on trunk! 
N 



1 / 



PREEMPT 



, — RESUME 



at time, t 

\ 



l~ 

! 7E 

i 


8LK1 


IB 




TB 


7E 


8LK2 I 8LK3 


TB 











time 



9 



EP 0 684 719 A1 



BO Bl B2 B3 BA B5 B6 B7 



1 i 1 

CHECKSUM 
1 1 1 


RESV 


TYPE 


PB 


RB 



SENDER 


L 




L 


RECEIVER 


TRUNK 
(PREEMPT 
RESUME - 


X 


DATA SEQUENCES 


R 


TRUNK 
(PREEMPT 
RESUME - 


M 
T 


(Tl LINE) 


£ 

C 


SEGMNTNG 


T 




V 


ASSEMBLY 



PACKET DATA 



F I NRT 



r 



REFERENCE NOTE 



(n) 



TXXX F 



4i 4i 



-TYPE OF PACKET: NRl 
PACKER HEADER 
-PACKET STARING FLAG 

TRAITER BYTE — 
NAME 



RT TXXX 



(NRT) 



NRT 



/ 



(p) 



^T 



/ 



(PACKET CONTINUATION) 



TYPE OF PACKET: RT 
PACKER HEADER 
BLOCK/ PACKET 
ENDING/ STARTING FLAG 



FIG . 5 



10 



EP 0 684 719 A1 



NRT 



(1) 



TlOO |F 



(1) 



F RT TOOO IF 



(1) 



(3) 





F NRT TllO F 




F (NRT) TlOljF 






FlRT TOlljF 





(2) 
FIG . 8 



(I) 



F I TllO |f 



(4) 



F |(NRT) T10l| F 



F 1 RT TOIoIf [rT TOlO F RT T011|f 



(2) 



(2) 



(3) 



(I) 



(3) 



(5) 



F |nRT TllO I F 




F 1 (NRT) Tin F 




, TlOllF 

fUnrt) ' 




f|rT TOll |f 




F RT TOlO F IrT TOll | F 





(2) 



(A) (2) 



FIG . 1 O 



11 



# 



EP 0 684 719 A1 



IDLE 



RT =REAL TIME 
NRT=NON REAL TIME 
TB =TRAITER BYTE 



NO RVCD DATA 



RECEIVE PKT/ BLOCK 





ENQUEUE 


RT PACKET 








<3- 


ENQUEUE 


NRT PACKET 




PR RT STATE 



START NRTPKT ASSMBL 



RECEIVE RT PACKET 



ENQUEUE RT PACKET 




ENQUEUE RT PACKET 



PR NRT STATE 



.0 



A 



FIG . 1 2 A 



14 



EP 0 684 719 A1 




15 



EP 0 684 719 A1 



f 



H 



H 



0 
H 



2 

:d 

PC 
H 



0 

H 



oo 



H 


X 











vO 
-3- 









g 


o 




-< 

























/I 






1 








c:x3 






X 


>» 






CQ 













"71 















I— » 


W 






2: 




O 










CQ 


pc: 


1 










1 


-< 




3C 






O 






l-H 




•< 


3C 









ME 


PC 








pe: 


E-i 




o 


1 




HH 




CQ 


Pi 






CU 






1 


pc: 










o 








O 






z 





T 









< 








§ 










< 


OEJ 


OS 






E-* 


Oh 


t— 1 




CQ 














Pe: 








CO 






J 



W O 

^ pe: 

-< o 

PLi CO 




m 















PQ 






-*< 














:^ 












-< 


:=) 


M 




CQ 


Pi 






Pu 







I 



16 



J) 



Kuropean Patent 
OfTice 



EUROPEAN SEARCH REPORT 



Application Number 

EP 94 48 0047 



DOCUMENTS CONSIDERED TO BE RELEVANT 



Category 



D.X 



Citation of document with indication, where appropriate, 
of retevant passages 



EP-A-0 582 537 (INTERNATIONAL BUSINESS 
MACHINES) 

* page 2, line 39 - line 48 * 

* claims 1-8 * 

* figures 2,3 * 

US-A-4 510 599 (E.U. MEHMET) 

* abstract * 

* claims 21-23,28-30.32 * 

IBM TECHNICAL DISCLOSURE BULLETIN, 
vol.37. no.2A, February 1994. NEW YORK US 
pages 243 - 245 

'MAC layer handling of preemptive and 
nonpreempti ve priorities in buffer 
insertion LANs* 

* the whole document * 

EP-A-0 512 290 (INTERNATIONAL BUSINESS 
MACHINES) 

* abstract * 

* page 7, line 45 - line 58 * 



Relevant 
to claim 



CLASSIFICATION OF THE 
APPIJCATION 0nt.CL6) 



1-6 



H04L29/06 



1-6 



1-6 



1-6 



TECHNICAL FIELDS 
SEARCHED ant.a.6) 



H04L 



The present search report has been drawn up for all claims 



Ptac* of tcarch 

THE HAGUE 



Dile of a>M|>)«*^* *^ uarck 

2 December 1994 



Perez Perez, J 



CATEGORY OF QTED DOCUMENTS 

X : particultrly relevant if taken aJonc 

Y : particularly relevant if combined with mother 

document of the same category 
A : technological background 
O : non-written disclosure 
P : intemcdiatc document 



T : theory or principle underlying the invention 
E : earlier patent docuraeni, but published on. or 
after the filing ditc 

0 : document dted in the application 
L : document dted for other reasons 

1 : member of the same patent family, corresponding 

document 



